GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Programmfehler</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Programmfehler</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p><b>Programmfehler</b> oder <b>Softwarefehler</b> oder <b>Software-Anomalie</b>, häufig auch <b>Bug</b> (<a href="Englische_Sprache" title="Englische Sprache">englisch</a>) genannt, sind Begriffe aus der <a href="Softwaretechnik" title="Softwaretechnik">Softwaretechnik</a>, mit denen für Software-Systemkomponenten Abweichungen zu einem geforderten oder gewünschten Sollzustand bezeichnet werden. Diese können auftreten, wenn z. B. eine bestimmte Festlegung der <a href="Spezifikation" title="Spezifikation">Spezifikation</a> fehlerhaft ist oder falsch <a href="Implementierung" title="Implementierung">umgesetzt</a> wurde („Fehlhandlung“), und führen zunächst zu einem internen „Fehlerzustand“ im <a href="Computerprogramm" title="Computerprogramm">Programm</a>, der wiederum während der <a href="Computerprogramm#Übersetzung_und_Ausführung" title="Computerprogramm">Programmausführung</a> zu einem unerwarteten Verhalten oder Ergebnis führt oder führen kann („Fehlerwirkung“).

</p><p>Zur möglichst vollständigen Erkennung und Behebung von Programmfehlern wird üblicherweise in den Prozessen der <a href="Softwareentwicklung" class="mw-redirect" title="Softwareentwicklung">Softwareentwicklung</a>, d. h. vor dem tatsächlichen, „produktiven“ Einsatz von Software, die <a href="Projektphase" title="Projektphase">Projektphase</a> „<a href="Softwaretest" title="Softwaretest">Softwaretest</a>“ durchlaufen, wobei eine Validierung durchgeführt wird. Dabei auftretende Fehler sind üblich und sie zu finden ist Ziel des Testens,<sup id="cite_ref-PKS_1-0" class="reference"><a href="#cite_note-PKS-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> während Fehler im laufenden Betrieb je nach Fehlerwirkung u. U. kritische Anomalien/Störungen darstellen. In der Praxis treten <a href="Computerprogramm" title="Computerprogramm">Computerprogramme</a> ohne Programmfehler selten auf. Als Qualitätsmerkmal für Programme kennt man u. a. die <a href="Fehlerquotient#Fehlerdichte" title="Fehlerquotient">Fehlerdichte</a>. Sie bezeichnet die Anzahl an Fehlern pro 1.000 Zeilen Code (<a href="Lines_of_Code" title="Lines of Code">Kilo Source Lines of Code</a>) bzw. je <a href="Function_Point" class="mw-redirect" title="Function Point">Function Point</a>.

</p><p>Als spezielle Instrumente zur Suche nach den Ursachen für Fehler in Programmen sind sogenannte <a href="Debugger" title="Debugger">Debugger</a> hilfreich, mit denen ein Programm Schritt für Schritt ausgeführt und kontrolliert werden kann. Bei besonders kritischer Software (z. B. Flugzeugsteuerung) wird mitunter eine (aufwendige) <a href="Verifizierung#Automatisierte/formale_Verifikation" title="Verifizierung">formale Verifikation</a> durchgeführt.

</p><p>Zur Erfassung und Dokumentation werden sogenannte <i><a href="Bugtracker" title="Bugtracker">Bugtracker</a></i> (wie <a href="Bugzilla" title="Bugzilla">Bugzilla</a> oder <a href="Mantis_Bug_Tracker" title="Mantis Bug Tracker">Mantis</a>) eingesetzt. Diese nehmen sowohl <a href="Fehlerbericht" title="Fehlerbericht">Fehlerberichte</a> als auch Verbesserungsvorschläge und Wünsche (sog. <i><span lang="en"><a href="Feature-Request" title="Feature-Request">Feature-Requests</a></span></i>) der Nutzer oder allgemeine Vorgänge auf. Siehe auch <a href="Fehlermanagement" title="Fehlermanagement">Fehlermanagement</a>.

</p><p>Der Vorgang des Beseitigens eines Programmfehlers wird umgangssprachlich <i>Bugfixing</i> genannt. Das Ergebnis der Verbesserung wird in der Fachsprache als <i>Bugfix,</i> <a href="Patch_(Software)" title="Patch (Software)"><i>Patch</i></a> oder <i>Softwarepatch</i> bezeichnet.

</p>

<div class="mw-heading mw-heading2"><h2 id="Definitionen">Definitionen</h2></div>

<p>Ein Programm- oder Softwarefehler ist, angelehnt an die allgemeine Definition für „<a href="Fehler" title="Fehler">Fehler</a>“

</p>

<dl><dd>„Nichterfüllung einer Anforderung“.<sup id="cite_ref-ISO-9000_2-0" class="reference"><a href="#cite_note-ISO-9000-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup></dd></dl>

<p>Konkret definiert sich der Fehler danach als

</p>

<dl><dd>„Abweichung des IST (beobachtete, ermittelte, berechnete Zustände oder Vorgänge) vom SOLL (festgelegte, korrekte Zustände und Vorgänge), wenn sie die vordefinierte Toleranzgrenze [die auch 0 sein kann] überschreitet.“</dd></dl>

<p>Nach <a href="ISTQB" class="mw-redirect" title="ISTQB">ISTQB</a><sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> bildet sich der Begriff 'Fehler' aus den folgenden Zusammenhängen:

</p>

<ul><li>eine <i>Fehlhandlung</i> (englisch Error)</li></ul>

<dl><dd><dl><dd>„die menschliche Handlung, die zu einem Fehlerzustand führt ([nach IEEE 610])“</dd></dl></dd></dl>

<ul><li>… führt zu einem <i>Fehlerzustand</i> (engl. Defect)</li></ul>

<dl><dd><dl><dd>„Defekt (innerer Fehlerzustand) in einer Komponente oder einem System, der eine geforderte Funktion des Produktes beeinträchtigen kann …“</dd></dl></dd></dl>

<ul><li>der eine <i>Fehlerwirkung</i> (engl. Failure) nach sich ziehen kann</li></ul>

<dl><dd><dl><dd>„Die Manifestierung eines inneren Fehlers bei der Ausführung [des Programms] als ein inkorrektes Verhalten oder Resultat bzw. als Versagen des Systems.“</dd></dl></dd>

<dd>Beispiel <a href="Division_durch_null" class="mw-redirect" title="Division durch null">Division durch null</a>: <i>Fehlhandlung:</i> Null als möglicher Divisor wurde nicht geprüft/ausgeschlossen; <i>Fehlerzustand:</i> Das Programm ist (ggf. unbemerkt) fehlerhaft; <i>Fehlerwirkung:</i> Bei Auftreten eines Nullwerts als Divisor tritt während der <a href="Computerprogramm#Überblick" title="Computerprogramm">Ausführung</a> des Befehls ein <a href="Laufzeitfehler" title="Laufzeitfehler">Laufzeitfehler</a> auf.</dd></dl>

<p>Als <i>Synonym</i> für „Fehler“ oder ergänzend dazu sind auch Ausdrücke wie Problem, Defekt, Abweichung, Anomalie, Mangel gebräuchlich. Damit kann die „Fehlerschwere“ auch begrifflich unterschieden werden, z. B. die Verletzung von Vorschriften zum <a href="Programmierstil" title="Programmierstil">Programmierstil</a>, die Lieferung falscher Ergebnisse oder ein <a href="Programmabbruch" title="Programmabbruch">Programmabbruch</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="„Bug“_als_Synonym_für_Programmfehler"><span id=".E2.80.9EBug.E2.80.9C_als_Synonym_f.C3.BCr_Programmfehler"></span>„Bug“ als Synonym für Programmfehler</h2></div>

<p>Das Wort <i>bug</i> bedeutet im Englischen „<a href="Schnabelkerfe" title="Schnabelkerfe">Schnabelkerf</a>; <a href="Wanzen" title="Wanzen">Wanze</a>“ und umgangssprachlich „landlebender <a href="Gliederf%C3%BC%C3%9Fer" title="Gliederfüßer">Gliederfüßer</a>“ oder „(insektenartiges) <a href="Ungeziefer" title="Ungeziefer">Ungeziefer</a>“.<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup> Im <a href="Jargon" title="Jargon">Jargon</a> amerikanischer <a href="Ingenieur" title="Ingenieur">Ingenieure</a> ist seit dem späten 19. Jahrhundert die Bedeutung „Fehlfunktion“ oder auch „Konstruktionsfehler“ bezeugt; diesem Wortgebrauch liegt die (scherzhafte) Vorstellung zugrunde, dass sich kleines Krabbelvieh am Getriebe, der Leitung usw. zu schaffen macht. Die ältesten Belege sind zwei Briefe <a href="Thomas_Edison" class="mw-redirect" title="Thomas Edison">Thomas Edisons</a> aus dem Jahr 1878 an <a href="William_Orton" title="William Orton">William Orton</a>, den Präsidenten der Telegraphiegesellschaft <a href="Western_Union" title="Western Union">Western Union</a>, bzw. <a href="Tivadar_Pusk%C3%A1s" title="Tivadar Puskás">Tivadar Puskás</a>, den Erfinder der <a href="Telefonzentrale" class="mw-redirect" title="Telefonzentrale">Telefonzentrale</a>, in denen es heißt:

</p>

<p>“[…] I did find a ‘bug’ in my apparatus, but it was not in the telephone proper. It was of the genus ‘callbellum.’<sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup>”

</p>

</blockquote>

<p>„[…] Ich fand in der Tat einen ‚Bug‘ in meinem Apparat, allerdings nicht im Telefon selbst. Er war von der Gattung ‚callbellum‘.“

</p>

</blockquote></div><div class="cite" style="margin:-1em 0 1em 1em;">– <cite style="font-style:normal">Thomas Edison in einem Brief an William Orton, datiert auf den 3. März 1878</cite><sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup></div></div>

<p>sowie

</p>

<p>“The first step [in all of my inventions] is an intuition, and comes with a burst, then difficulties arise – this thing gives out and [it is] then that ‘Bugs’ – as such little faults and difficulties are called – show themselves […].”

</p>

</blockquote>

<p>„Der erste Schritt [bei all meinen Erfindungen] ist ein intuitiver Gedanke, der in einem Ausbruch kommt, doch dann tauchen Schwierigkeiten auf – das Ding funktioniert nicht mehr und [es ist] dann, dass ‚Bugs‘ – wie solche kleinen Fehler und Schwierigkeiten genannt werden – sich zeigen […].“

</p>

</blockquote></div><div class="cite" style="margin:-1em 0 1em 1em;">– <cite style="font-style:normal">Thomas Edison in einem Brief an Tivadar Puskás, datiert auf den 18. November 1878</cite></div></div>

<p>Edison ist zwar nicht Erfinder, aber immerhin Kronzeuge für eine schon damals kursierende Bedeutung des Wortes. Die Verknüpfung des Begriffs mit Computern geht möglicherweise auf die Computerpionierin <a href="Grace_Hopper" title="Grace Hopper">Grace Hopper</a> zurück. Sie verbreitete die Geschichte, dass am 9. September 1945 eine <a href="Nachtfalter" title="Nachtfalter">Motte</a> in einem Relais des Computers Mark II Aiken Relay Calculator zu einer Fehlfunktion führte. Die Motte wurde entfernt, in das <a href="Logbuch" title="Logbuch">Logbuch</a> geklebt und mit folgender Notiz versehen: “<span lang="en">First actual case of bug being found.</span>” (deutsch: „Das erste Mal, dass tatsächlich ein ‚Ungeziefer‘ gefunden wurde.“). Die Legende der Begriffsfindung hält sich hartnäckig, obwohl die Logbuch-Eintragung gerade darauf verweist, dass der Begriff schon zuvor gängig war. Zudem irrte Grace Hopper sich hinsichtlich des Jahres: Der Vorfall ereignete sich tatsächlich am 9. September 1947. Die entsprechende Seite des Logbuchs wurde bis Anfang der 1990er Jahre am <i>Naval Surface Warfare Center Computer Museum</i> der <a href="United_States_Navy" title="United States Navy">US-Marine</a> in Dahlgren, <a href="Virginia" title="Virginia">Virginia</a>, aufbewahrt. Zurzeit befindet sich diese Logbuchseite mit der Motte am <a href="Smithsonian_Institution" title="Smithsonian Institution">Smithsonian Institute</a>.<sup id="cite_ref-7" class="reference"><a href="#cite_note-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Arten_von_Programmfehlern">Arten von Programmfehlern</h2></div>

<p>In der <a href="Softwaretechnik" title="Softwaretechnik">Softwaretechnik</a> (siehe auch<sup id="cite_ref-UniO_8-0" class="reference"><a href="#cite_note-UniO-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup>) wird zwischen folgenden Typen von Fehlern in Programmen unterschieden:

</p>

<ul><li><i>Lexikalische Fehler</i> sind nicht interpretierbare Zeichenketten, also undefinierte Bezeichner (Variablen, Funktionen, <a href="Literale" class="mw-redirect" title="Literale">Literale</a>...)</li>

<li><i><a href="Syntaxfehler" title="Syntaxfehler">Syntaxfehler</a></i> sind Verstöße gegen die grammatischen Regeln der benutzten <a href="Programmiersprache" title="Programmiersprache">Programmiersprache</a>, zum Beispiel die falsche Verwendung reservierter Symbole (z. B. fehlende Klammern), Typkonflikte, falsche Anzahl Parameter.</li></ul>

<p>Lexikalische und Syntaxfehler verhindern in der Regel die <a href="Compiler" title="Compiler">Kompilierung</a> des fehlerhaften Programms und werden daher frühzeitig erkannt. Bei Programmiersprachen, die sequentiell <a href="Interpreter" title="Interpreter">interpretiert</a> werden, bricht das Programm üblicherweise erst an der syntaktisch/lexikalisch fehlerhaften Stelle ab.

</p>

<ul><li><i><a href="Formale_Semantik" title="Formale Semantik">Semantische Fehler</a></i> sind Fehler, in denen eine programmierte Anweisung zwar syntaktisch fehlerfrei, aber inhaltlich trotzdem fehlerhaft ist, zum Beispiel Verwechslung des Befehlscodes, syntaktisch nicht erkennbare falsche Parameterreihenfolge.</li>

<li><i><a href="Logik" title="Logik">Logische Fehler</a></i> bestehen in einem im Detail falschen Problemlösungsansatz, beispielsweise auf Grund eines <a href="Fehlschluss" title="Fehlschluss">Fehlschlusses</a>, einer falsch interpretierten <a href="Spezifikation" title="Spezifikation">Spezifikation</a> oder einfach eines Versehens oder Schreibfehlers. Beispiele: plus statt minus, kleiner statt kleiner/gleich usw. Die Toleranz gegenüber solchen Fehlern und die diese einschränken sollende <a href="Attributgrammatik" title="Attributgrammatik">Attributgrammatik</a> von Programmiersprachen, wie etwa bei der <a href="Zuweisungskompatibilit%C3%A4t" title="Zuweisungskompatibilität">Zuweisungskompatibilität</a> von <a href="Datentyp" title="Datentyp">Datentypen</a>, sind je nach verwendeter <a href="Programmiersprache" title="Programmiersprache">Programmiersprache</a> sehr unterschiedlich ausgeprägt und können schwierig zu überschauende <a href="Sicherheitsl%C3%BCcke" title="Sicherheitslücke">Sicherheitslücken</a> und <a href="Absturz_(Computer)" title="Absturz (Computer)">Programmabstürze</a> verursachen.</li>

<li><i>Designfehler</i> sind Fehler im Grundkonzept, entweder bei der Definition der <a href="Anforderung_(Informatik)" title="Anforderung (Informatik)">Anforderungen</a> an die <a href="Software" title="Software">Software</a>, oder bei der Entwicklung des Softwaredesigns, auf dessen Grundlage das Programm entwickelt wird. Fehler bei der <a href="Anforderungsdefinition" class="mw-redirect" title="Anforderungsdefinition">Anforderungsdefinition</a> beruhen oft auf mangelnder Kenntnis des Fachgebietes, für das die Software geschrieben wird oder auf Missverständnissen zwischen Nutzern und Entwicklern. Fehler direkt im <a href="Softwaredesign" title="Softwaredesign">Softwaredesign</a> hingegen sind oft auf mangelnde Erfahrung der <a href="Softwareentwickler" title="Softwareentwickler">Softwareentwickler</a>, un<a href="Strukturierte_Programmierung" title="Strukturierte Programmierung">strukturierte Programmierung</a> oder auf Folgefehler durch Fehler in der <a href="Anforderungserhebung" class="mw-redirect" title="Anforderungserhebung">Anforderungsspezifikation</a> zurückzuführen. In anderen Fällen ist das Design historisch gewachsen und wird mit der Zeit unübersichtlich, was wiederum zu Designfehlern bei Weiterentwicklungen des Programms führen kann. Oftmals wird ohne Vorliegen eines richtigen <a href="DV-Konzept" title="DV-Konzept">Konzepts</a> direkt programmiert, was dann insbesondere bei höherem Komplexitätsgrad der Software zu Designfehlern führen kann. Sowohl für Fehler in der Anforderungsdefinition als auch im Softwaredesign kommen darüber hinaus vielfach Kosten- oder Zeitdruck in Frage. Ein typischer Designfehler ist die <a href="Codewiederholung" class="mw-redirect" title="Codewiederholung">Codewiederholung</a>, die zwar nicht unmittelbar zu Programmfehlern führt, aber bei der <a href="Softwarewartung" title="Softwarewartung">Softwarewartung</a>, der Modifikation oder der Erweiterung von Programmcode sehr leicht übersehen werden kann und dann unweigerlich zu unerwünschten Effekten führt.</li>

<li>Fehler im <i>Bedienkonzept.</i> Das Programm verhält sich anders als es einzelne oder viele Anwender erwarten, obwohl es technisch an sich fehlerfrei arbeitet.</li></ul>

<p><b>Sonstige Fehlerbegriffe</b>

</p>

<ul><li><i><a href="Laufzeitfehler" title="Laufzeitfehler">Laufzeitfehler</a>:</i> Während die vorgenannten Fehler ein tatsächlich fehlerhaftes Programm bedeuten, das entweder nicht ausführbar ist oder fehlerhafte Ergebnisse liefert, kann auch ein „korrektes“ Programm bei seiner Ausführung zu Fehlern führen. Laufzeitfehler sind alle Arten von Fehlern, die auftreten, während das Programm abgearbeitet wird. Je nach Situation kann die Ursache beispielsweise eine unpassenden Programmumgebung sein (z. B. eine falsche <a href="Betriebssystem" title="Betriebssystem">Betriebssystem</a>-Version, falsche <a href="Parameter_(Informatik)" title="Parameter (Informatik)">Parameter</a> beim Aufruf des Programms (auch als <a href="Unterprogramm" title="Unterprogramm">Unterprogramm</a>), falsche Eingabedaten etc.)</li></ul>

<dl><dd>Laufzeitfehler können sich auf die unterschiedlichsten Arten zeigen. Oftmals zeigt das Programm ungewünschtes Verhalten, im Extremfall wird die Ausführung des Programms abgebrochen („Absturz“), oder das Programm geht in einen Zustand über, in dem es keine Benutzereingaben mehr akzeptiert („Einfrieren“, „Hängen“). Wird in Programmiersprachen ohne <a href="Garbage_Collection" title="Garbage Collection">automatische Speicherbereinigung</a> (etwa <a href="C_(Programmiersprache)" title="C (Programmiersprache)">C</a> oder <a href="C%2B%2B" title="C++">C++</a>) Speicher nach der Verwendung nicht mehr freigegeben, so wird durch das Programm auf Dauer immer mehr Speicher belegt. Diese Situation wird <a href="Speicherleck" title="Speicherleck">Speicherleck</a> genannt. Aber auch in Programmiersprachen mit <a href="Garbage_Collection" title="Garbage Collection">automatischer Speicherbereinigung</a> (etwa <a href="Java_(Programmiersprache)" title="Java (Programmiersprache)">Java</a> oder <a href="C-Sharp" title="C-Sharp">C#</a>) können ähnliche Probleme auftreten, wenn zum Beispiel Objekte durch <a href="Systemprogrammierung" title="Systemprogrammierung">systemnahe Programmierung</a> unkontrolliert angesammelt werden. Noch kritischer sind versehentlich vom <a href="Programmierer" class="mw-redirect" title="Programmierer">Programmierer</a> freigegebene Speicherbereiche, die oft trotzdem noch durch <a href="H%C3%A4ngender_Zeiger" title="Hängender Zeiger">hängende Zeiger</a> referenziert werden, da dies zu völlig unkontrolliertem Verhalten der Software führen kann. Manche <a href="Laufzeitumgebung" title="Laufzeitumgebung">Laufzeitumgebungen</a> erlauben daher solche programmierbaren Speicherfreigaben grundsätzlich nicht. Des Weiteren gibt es auch Bugs im Zusammenspiel mit anderen Programmen.</dd></dl>

<ul><li>Fehler im <i>Compiler, der Laufzeitumgebung oder sonstigen Bibliotheken.</i> Solche Fehler sind meist besonders schwer nachzuvollziehen, da das Verhalten des Programms in solchen Fällen nicht seiner Semantik entspricht. Insbesondere von Compiler und Laufzeitumgebung wird daher besondere Zuverlässigkeit erwartet.</li>

<li>Ein <i>Regressionsbug</i> (<i>Regression</i> bedeutet „Rückschritt“) ist ein Fehler, der erst in einer späteren Programmversion auftaucht. Dies sind häufig unerkannte Nebeneffekte von Fehlerbehebungen oder Programmänderungen an anderer Stelle.</li>

<li>Fehler als Folge physikalischer <i>Betriebsbedingungen.</i> Verschiedenste Begebenheiten wie elektromagnetische Felder, Strahlen, Temperaturschwankungen, Erschütterungen usw. können auch bei sonst einwandfrei konfigurierten und innerhalb der Spezifikationen betriebenen Systemen zu Fehlern führen. Fehler dieses Typs sind sehr unwahrscheinlich, können nur sehr schwer festgestellt werden und haben bei Echtzeitanwendungen unter Umständen fatale Folgen. Sie dürfen aber aus statistischen Gründen nicht ausgeschlossen werden. Das berühmte „Umfallen eines Bits“ im Speicher oder auf der Festplatte auf Grund der beschriebenen Einflüsse stellt zum Beispiel solch einen Fehler dar. Da die Auswirkungen eines solchen Fehlers (z. B. Absturz des Systems oder Boot-Unfähigkeit, weil eine Systemdatei beschädigt wurde) von denen anderer Programmfehler meist nur sehr schwer unterschieden werden können, vermutet man oft eine andere Ursache, zumal ein solcher Fehler häufig nicht reproduzierbar ist.</li>

<li><i>Programmfehler vs. Softwarefehler:</i> Soweit diese beiden Bezeichnungen <i>nicht</i> als Synonyme verstanden werden, kann – entsprechend dem Bedeutungsunterschied zwischen <a href="Computerprogramm" title="Computerprogramm">Computerprogramm</a> und <a href="Software#Definition" title="Software">Software</a> – auch für ‚Softwarefehler‘ eine breitere Definition zutreffen: Danach wären etwa auch Fehler oder Mängel in der Dokumentation Softwarefehler, unabhängig davon, ob sie zu fehlerhaften Programmen führten. Auch dürften fehlerhafte <a href="Daten" title="Daten">Daten</a> (auch dieser Begriff wird je nach Definition der Software zugerechnet) kaum als Programm-, sondern, wenn überhaupt, höchstens als Softwarefehler gelten.</li>

<li><i><a href="Technische_Schulden" title="Technische Schulden">Technische Schulden</a> und Qualitätsmängel:</i> Gemäß ISO 9000 ist ein Fehler die „Nichterfüllung einer Anforderung“. Anforderungen wiederum werden definiert als „Erfordernis oder Erwartung, das oder die festgelegt, üblicherweise vorausgesetzt oder verpflichtend ist“.<sup id="cite_ref-ISO-9000_2-1" class="reference"><a href="#cite_note-ISO-9000-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> Dazu gehört auch das Nichtvorhandensein von technischen Schulden oder sonstigen Qualitätsmängeln.</li></ul>

<p>Bei manchen Projekten wird nicht der Begriff Bug verwendet, sondern man spricht zum Beispiel von Metabugs, bei denen ein Bug ein Element einer Aufgabenliste darstellt. Bei einigen Projekten spricht man stattdessen auch von „Issues“ (Angelegenheiten), da sich dieser Ausdruck nicht auf Programmfehler beschränkt.

</p><p>Konkrete Beispiele von Fehlern mit medial besonderer Wirkung finden sich in der <a href="Liste_von_Programmfehlerbeispielen" title="Liste von Programmfehlerbeispielen">Liste von Programmfehlerbeispielen</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Wirtschaftliche_Bedeutung">Wirtschaftliche Bedeutung</h2></div>

<p>Softwarefehler sind weit mehr als nur ärgerliche Begleitumstände für Softwareentwickler, sondern sie verursachen aus betriebswirtschaftlicher und ökonomischer Sicht erhebliche <i>Kosten.</i> Die IX-Studie 1/2006<sup id="cite_ref-9" class="reference"><a href="#cite_note-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup> zeigte z. B. folgende für Deutschland ermittelte Werte:

</p>

<ul><li>Ca. 84,4 Mrd. Euro betragen die <i>jährlichen Verluste</i> durch Softwarefehler in Mittelstands- und Großunternehmen</li>

<li>Ca. 14,4 Mrd. Euro jährlich (35,9 % des IT-Budgets) werden für die <i>Beseitigung von Programmfehlern</i> verwendet;</li>

<li>Ca. 70 Mrd. Euro betragen die <i>Produktivitätsverluste</i> durch Computerausfälle aufgrund fehlerhafter Software</li></ul>

<p>In derselben Studie wird auch die Entwicklung der <a href="Softwarequalit%C3%A4t" title="Softwarequalität">Softwarequalität</a> für die Zeit von 2002 bis 2004 untersucht – mit dem Ergebnis:

</p>

<ul><li>die Quote gescheiterter Projekte stieg von 15 % auf 18 %</li>

<li>die Quote erfolgreicher Projekte sank von 34 % auf 29 %</li>

<li>die Quote der Projekte mit Kostenüberschreitung stieg von 43 % auf 56 %</li>

<li>die Quote der Projekte mit Terminüberschreitung stieg von 82 % auf 84 %</li>

<li>die Quote der Projekte mit passender Funktionalität sank von 67 % auf 64 %</li></ul>

<p>Für die USA werden die Kosten von Programmierfehlern 2022 auf 2,41 Billionen Dollar geschätzt, davon 1,81 Billionen für Fehler im Betrieb, 607 Milliarden für die Fehlersuche und -behebung und 260 Milliarden für fehlerbedingte Projektabbrüche.<sup id="cite_ref-10" class="reference"><a href="#cite_note-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>

</p><p>Besonders viele Misserfolge zeigt ein Bericht des obersten Rechnungshofs für neue Projekte (1985) bei der US-Bundesverwaltung,<sup id="cite_ref-Wallm_SWQ_11-0" class="reference"><a href="#cite_note-Wallm_SWQ-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup> wonach

</p>

<ul><li>27 % der bezahlten Software nie geliefert wurden,</li>

<li>52 % nie funktionierten,</li>

<li>18 % erst nach einer aufwändigen Sanierung zum Einsatz kamen.</li>

<li>Lediglich 3 % der in Auftrag gegebenen Software erfüllten die vereinbarten Vertragsbedingungen.</li></ul>

<p>Die Standish Group International stellte fest:<sup id="cite_ref-12" class="reference"><a href="#cite_note-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup> Durchschnittlich überschreiten Projekte

</p>

<ul><li>die ursprünglich geplanten Projektkosten um 89 %</li>

<li>die geplanten Termine um 222 %.</li></ul>

<p>Als <i>Gründe für Projektabbrüche</i> aufgrund schlechter Softwarequalität ermittelte Ewusi-Menach folgende Faktoren:<sup id="cite_ref-Wallm_SWQ_11-1" class="reference"><a href="#cite_note-Wallm_SWQ-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup>

</p>

<ul><li>Unklare Zielsetzung</li>

<li>Falsche Projektteambesetzung</li>

<li>Unzulängliche Qualitätssicherung</li>

<li>Fehlendes technisches Know-how</li>

<li>Unzureichende Berücksichtigung der Ausgangssituation</li>

<li>Mangelnde Beteiligung der Anwender</li></ul>

<p>Die Kosten für Debugging und Beseitigung bei in späteren Projektphasen bzw. in Produktion gefundenen Fehlern übersteigen üblicherweise die Kosten für das Verhindern und Finden von Fehlern.<sup id="cite_ref-13" class="reference"><a href="#cite_note-13"><span class="cite-bracket">[</span>13<span class="cite-bracket">]</span></a></sup> Studien belegen daher, dass es oft günstiger ist, qualitativ hochwertige Software zu entwickeln, als qualitativ minderwertige.<sup id="cite_ref-14" class="reference"><a href="#cite_note-14"><span class="cite-bracket">[</span>14<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Vermeidung,_Auffindung_und_Behebung_von_Programmfehlern"><span id="Vermeidung.2C_Auffindung_und_Behebung_von_Programmfehlern"></span>Vermeidung, Auffindung und Behebung von Programmfehlern</h2></div>

<p>Generell gilt:<sup id="cite_ref-15" class="reference"><a href="#cite_note-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup> <i>Je früher im Entwicklungsprozess der Fehler auftritt und je später er entdeckt wird, umso aufwändiger wird es, den Fehler zu beheben.</i>

Im Schnitt rechnet man mit Kosten von 16.000 Dollar je in Produktion gefundenem Bug, während die Kosten für das Verhindern von Fehlern während der Designphase bei 25 Dollar liegen.<sup id="cite_ref-16" class="reference"><a href="#cite_note-16"><span class="cite-bracket">[</span>16<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Während_der_Planung"><span id="W.C3.A4hrend_der_Planung"></span>Während der Planung</h3></div>

<p>Am wichtigsten ist eine gute und geeignete Planung des Entwicklungsprozesses. Hierfür gibt es bereits etliche <a href="Vorgehensmodell_zur_Softwareentwicklung" title="Vorgehensmodell zur Softwareentwicklung">Vorgehensmodelle</a>, aus denen ein geeignetes ausgewählt werden kann.

</p>

<div class="mw-heading mw-heading3"><h3 id="In_der_Analysephase">In der Analysephase</h3></div>

<p>Ein Problem ist, dass die Korrektheit eines Programms nur gegen eine entsprechend formalisierte Spezifikation bewiesen werden kann. Eine solche Spezifikation zu erstellen kann jedoch im Einzelfall ähnlich kompliziert und fehlerträchtig sein, wie die Programmierung des Programms selbst.

</p>

<div class="mw-heading mw-heading3"><h3 id="In_der_Entwurfsphase">In der Entwurfsphase</h3></div>

<p>Softwareexperten sind sich darüber einig, dass praktisch jedes nicht-triviale Programm Fehler enthält. Deshalb wurden Techniken entwickelt, mit Fehlern innerhalb von Programmen tolerant umzugehen. Zu diesen Techniken gehören <a href="Defensives_Programmieren" title="Defensives Programmieren">defensives Programmieren</a>, <a href="Ausnahmebehandlung" title="Ausnahmebehandlung">Ausnahmebehandlung</a>, <a href="Redundanz_(Informationstheorie)" title="Redundanz (Informationstheorie)">Redundanz</a> und die Überwachung von Programmen (z. B. durch <a href="Watchdog" title="Watchdog">Watchdog</a>-Timer) sowie die <a href="Plausibilisierung" class="mw-redirect" title="Plausibilisierung">Plausibilisierung</a> des Programmes während der Entwicklung und der Daten während des Programmablaufs.

</p>

<div class="mw-heading mw-heading3"><h3 id="Bei_der_Programmierung">Bei der Programmierung</h3></div>

<p>Die Entwicklung immer abstrakterer <a href="Programmierparadigma" title="Programmierparadigma">Programmierparadigmen</a> und <a href="Programmierstil" title="Programmierstil">Programmierstile</a> wie die <a href="Funktionale_Programmierung" title="Funktionale Programmierung">funktionale Programmierung</a>, <a href="Objektorientierte_Programmierung" title="Objektorientierte Programmierung">objektorientierte Programmierung</a>, <a href="Design_by_contract" class="mw-redirect" title="Design by contract">Design by contract</a> und die <a href="Aspektorientierte_Programmierung" title="Aspektorientierte Programmierung">aspektorientierte Programmierung</a> dienen unter anderem der Fehlervermeidung und Vereinfachung der Fehlersuche. Aus den zur Verfügung stehenden Techniken für das Problem ist eine geeignete auszuwählen. Ein wichtiger Punkt hierbei ist aber auch, dass für das jeweilige Paradigma erfahrene Programmierer zur Verfügung stehen müssen, sonst entsteht oft der gegenteilige Effekt.

</p><p>Ferner ist es sehr nützlich, von den Entwicklungswerkzeugen möglichst viele Aufgaben der Fehlervermeidung zuverlässig und automatisch erledigen zu lassen, was z. B. mit Hilfe von <a href="Strukturierte_Programmierung" title="Strukturierte Programmierung">strukturierter Programmierung</a> erleichtert wird. Dies betrifft zum einen bereits Kontrollen wie <a href="Variable_(Programmierung)#Sichtbarkeitsbereich_von_Variablen_(Scope)" title="Variable (Programmierung)">Sichtbarkeitsregeln</a> und <a href="Typsicherheit" title="Typsicherheit">Typsicherheit</a>, sowie die Vermeidung von <a href="Zirkelbezug" title="Zirkelbezug">Zirkelbezügen</a>, die bereits vor der Übersetzung von Programmen vom <a href="Compiler" title="Compiler">Compiler</a> übernommen werden können, aber auch Kontrollen, die erst zur <a href="Laufzeit_(Informatik)" title="Laufzeit (Informatik)">Laufzeit</a> durchgeführt werden können, wie zum Beispiel <a href="Buffer_Overflow" class="mw-redirect" title="Buffer Overflow">Indexprüfung</a> bei <a href="Feld_(Datentyp)" class="mw-redirect" title="Feld (Datentyp)">Datenfeldern</a> oder <a href="Typsicherheit" title="Typsicherheit">Typprüfung</a> bei Objekten der objektorientierten Programmierung.

</p><p>Darüber hinaus wird eine Reihe fortgeschrittener Anwendungen angeboten, die entweder den <a href="Quellcode" class="mw-redirect" title="Quellcode">Quellcode</a> oder den <a href="Bin%C3%A4rcode" title="Binärcode">Binärcode</a> analysieren und versuchen, häufig gemachte Fehler automatisiert zu finden. In diese Kategorie fallen etwa Programme zur Ausführungsüberwachung, die üblicherweise fehlerhafte Speicherzugriffe und <a href="Speicherleck" title="Speicherleck">Speicherlecks</a> zuverlässig aufspüren. Beispiele sind das frei erhältliche Tool <a href="Valgrind" title="Valgrind">Valgrind</a> und das kommerzielle Purify. Eine weitere Kategorie von Prüfprogrammen umfasst Anwendungen, die Quell- oder Binärcode statisch analysieren und etwa nicht geschlossene Ressourcen und andere Probleme auffinden und melden können. Darunter fallen etwa <a href="FindBugs" title="FindBugs">FindBugs</a>, <a href="Lint_(Programmierwerkzeug)" title="Lint (Programmierwerkzeug)">Lint</a> und <a href="Splint_(Software)" title="Splint (Software)">Splint</a>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Beim_Testen">Beim Testen</h3></div>

<p>Es ist durchaus sinnvoll, dass der <a href="Softwaretest" title="Softwaretest">Test</a> vor dem eigentlichen Programm entwickelt wird. Damit wird erreicht, dass nicht ein Test geschrieben wird, der zu dem bereits geschriebenen Programm <i>passt</i>. Dies kann durch Ermittlung von <a href="Testfall" title="Testfall">Testfällen</a> anhand der <a href="Spezifikation" title="Spezifikation">Spezifikation</a> bereits während der Analyse- bzw. Designphase erfolgen. Die Ermittlung von Testfällen in diesem frühen Stadium der Softwareentwicklung ermöglicht zudem die Prüfung der Anforderungen an das Programm auf Testbarkeit und Vollständigkeit. Die anhand der Spezifikation ermittelten Testfälle sind die Basis für die Abnahmetests – die kontinuierlich über den gesamten Entwicklungsprozess verfeinert und z. B. für eine <a href="Testautomatisierung" title="Testautomatisierung">Testautomatisierung</a> vorbereitet werden können.

</p><p>Manche Softwareanbieter führen Testphasen teilweise öffentlich durch und geben <a href="Betaversion" class="mw-redirect" title="Betaversion">Betaversionen</a> heraus, um die unvorhersehbar vielfältigen Nutzungsbedingungen verschiedener Anwender durch diese selbst testen und kommentieren zu lassen.

</p>

<div class="mw-heading mw-heading3"><h3 id="Im_Betrieb">Im Betrieb</h3></div>

<p>Tritt ein Fehler während des Betriebs auf, so muss versucht werden, seine Auswirkungen möglichst gering zu halten und seinen Wirkungskreis durch Schaffung von „Schutzwällen“ oder „Sicherungen“ einzudämmen. Dies erfordert zum einen Möglichkeiten der Fehlererkennung und zum anderen, adäquat auf einen Fehler reagieren zu können.

</p><p>Ein Beispiel zur Fehlererkennung zur Laufzeit eines Computerprogrammes sind <a href="Assertion_(Informatik)" title="Assertion (Informatik)">Assertions</a>, mit deren Hilfe Bedingungen abgefragt werden, die gemäß Programmdesign immer erfüllt sind. Weitere Mechanismen sind <a href="Ausnahmebehandlung" title="Ausnahmebehandlung">Ausnahmebehandlungen</a> wie Trap und Exception.

</p><p>Durch die Implementierung von <a href="Proof-Carrying_Code" title="Proof-Carrying Code">Proof-Carrying Code</a> kann die Software zur Laufzeit ihre Zuverlässigkeit in gewissem Rahmen gewährleisten und sicherstellen.

</p>

<div class="mw-heading mw-heading2"><h2 id="Fehlerfreiheit">Fehlerfreiheit</h2></div>

<p>Völlige Fehlerfreiheit für Software, die eine gewisse Komplexitätsgrenze überschreitet, ist praktisch weder erreich- noch nachweisbar. Mit steigender Komplexität sinkt die Überblickbarkeit, insbesondere auch, wenn mehrere Personen an der Programmierung beteiligt sind. Selbst teure oder vielfach getestete Software enthält Programmierfehler. Man spricht dann bei gut brauchbaren Programmen nicht von Fehlerfreiheit, sondern von <a href="Robustheit" title="Robustheit">Robustheit</a>. Eine Software gilt dann als robust, wenn Fehler nur sehr selten auftreten und diese dann nur kleinere Unannehmlichkeiten mit sich bringen und keine größeren Schäden oder Verluste verursachen.

</p><p>In Spezialfällen ist ein <a href="Beweis_(Logik)" title="Beweis (Logik)">Beweis</a> der Fehlerfreiheit (bzgl. der festgelegten Anforderungen) eines Programms möglich. Insbesondere in Bereichen, in denen der Einsatz von Software mit hohen finanziellen, wirtschaftlichen oder menschlichen Risiken verbunden ist, wie z. B. bei militärisch oder medizinisch genutzter Software oder in der Luft- und Raumfahrt, verwendet man zudem eine „(formale) <a href="Verifizierung#Informatik_(Verifizieren_von_Software)" title="Verifizierung">Verifizierung</a>“ genannte Methode, bei der die Korrektheit einer Software formal-mathematisch nachgewiesen wird. Dieser Methode sind allerdings wegen des enormen Aufwands enge Grenzen gesetzt und sie ist daher bei komplexen Programmen praktisch unmöglich durchzuführen (siehe auch <a href="Berechenbarkeit" title="Berechenbarkeit">Berechenbarkeit</a>). Allerdings gibt es mittlerweile Werkzeuge, die diesen Nachweis laut eigenen Angaben zumindest für Teilbereiche (<a href="Laufzeitfehler" title="Laufzeitfehler">Laufzeitfehler</a>) schnell und zuverlässig erbringen können.

</p><p>Neben der mathematischen Verifizierung gibt es noch eine praxistaugliche Form der Verifizierung, die durch die Qualitätsmanagement-Norm <a href="ISO_9000" class="mw-redirect" title="ISO 9000">ISO 9000</a> beschrieben wird. Bei ihr wird <i>formal</i> nur dann ein <a href="Fehler" title="Fehler">Fehler</a> konstatiert, wenn eine <a href="Anforderung_(Informatik)" title="Anforderung (Informatik)">Anforderung</a> nicht erfüllt ist. Umgekehrt kann demnach ein Arbeitsergebnis (und damit auch <a href="Software" title="Software">Software</a>) als ‚fehlerfrei‘ bezeichnet werden, wenn es nachweisbar alle Anforderungen erfüllt. Die Erfüllung einer Anforderung wird dabei durch <a href="Test" title="Test">Tests</a> festgestellt. Bringen alle zu einer Anforderung definierten Tests die erwarteten Ergebnisse, so ist die Anforderung erfüllt. Gilt dies für die Tests aller Anforderungen (korrektes und vollständiges Testen vorausgesetzt), so wird „fehlerfrei bzgl. der Anforderungen“ gefolgert. Sind die den Tests zugrundeliegenden Anforderungen fehlerhaft oder unvollständig, so arbeitet die Software dementsprechend dennoch nicht „wie gewünscht“.

</p>

<div class="mw-heading mw-heading2"><h2 id="Klassifizierung_von_Fehlern">Klassifizierung von Fehlern</h2></div>

<p>Aufgetretene Fehler werden im Allgemeinen im <a href="Fehlermanagement" title="Fehlermanagement">Fehlermanagement</a> systematisch bearbeitet. Nach der IEEE-Norm 1044 (Klassifizierung von Softwareanomalien) durchläuft dabei jeder Fehler einen sogenannten Klassifizierungsprozess, bestehend aus den vier Schritten Erkennung (Recognition), Analyse (Investigation), Bearbeitung (Action) und Abschluss (Disposition).<sup id="cite_ref-17" class="reference"><a href="#cite_note-17"><span class="cite-bracket">[</span>17<span class="cite-bracket">]</span></a></sup> In jedem dieser Schritte werden die Verwaltungsaktivitäten Aufzeichnen (Recording), Klassifizieren (Classifying), Wirkung identifizieren (Identifying Impact) ausgeführt.<sup id="cite_ref-IEEE_1044en_18-0" class="reference"><a href="#cite_note-IEEE_1044en-18"><span class="cite-bracket">[</span>18<span class="cite-bracket">]</span></a></sup>

</p><p>Kriterien, nach denen Fehler dabei <i>klassifiziert</i> werden können, sind u. a. (mit Beispielen):

</p>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Fehlerklassifizierung" title="Fehlerklassifizierung">Fehlerklassifizierung</a></i></div>

<ul><li>die Art des Fehlers: Nach<sup id="cite_ref-UniO_8-1" class="reference"><a href="#cite_note-UniO-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup> werden dabei unterschieden: Lexikalische Fehler (unbekannter Bezug), syntaktische Fehler (vergessenes Semikolon), semantische Fehler (falsche <a href="Deklaration_(Programmierung)" title="Deklaration (Programmierung)">Deklaration</a>), Laufzeitfehler (falsch formatierte Eingabedaten) und logische Fehler (plus statt minus, <a href="Schleife_(Programmierung)" title="Schleife (Programmierung)">Schleifenfehler</a>, …)</li>

<li>die Fehlerursache: unpräzise Vorgabe, Zahlendreher, falsche Formel, nicht geprüfte (falsche) Eingabedaten …</li>

<li>der Zeitpunkt der Fehlerentstehung (‚Fehlhandlung‘): Bereits bei der Programmvorgabe, im Codeentwurf, beim Codieren, …</li>

<li>der Zeitpunkt des Fehlerauftretens (‚Fehlerwirkung‘): Ein grundsätzlicher Unterschied ergibt sich daraus, ob der Fehler während der Programmentwicklung auftritt, zum Beispiel beim Testen (hier ist dies ein Normalfall<sup id="cite_ref-PKS_1-1" class="reference"><a href="#cite_note-PKS-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>) oder im <a href="Produktivbetrieb" title="Produktivbetrieb">produktiven</a> Betrieb (wo er häufig eine kritische Störung darstellt).</li>

<li>der Zeitpunkt der Entdeckung: Je länger die „Fehlerverweilzeit“ ist, desto aufwändiger wird i. A. die Korrekturmaßnahme verlaufen.</li>

<li>die Reproduzierbarkeit des Fehlers: Je schwieriger ein Fehler reproduzierbar ist, desto aufwändiger wird i. A. die Korrekturmaßnahme verlaufen.</li>

<li>die Auswirkung(en) des Fehlers: Darstellungsfehler, falsches Ergebnis, Programmabbruch, Außenwirkung …</li>

<li>Aufwand und Dauer zur Fehlerbehebung: minimal … sehr hoch; sofort … sehr lange Dauer;</li>

<li>Bearbeitungsstatus: aufgetreten, untersucht, Korrekturauftrag in Bearbeitung, <a href="Regressionstest" title="Regressionstest">Retest</a> möglich, …, erledigt</li></ul>

<p>Mit Hilfe von <a href="Softwaremetrik" title="Softwaremetrik">Metriken</a> „sollten die Ergebnisse [und Erkenntnisse über Fehler] auch Anlass zur Suche nach den <i>Ursachen</i> hinter den Problemen sein“.<sup id="cite_ref-PKS_1-2" class="reference"><a href="#cite_note-PKS-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> „Fehlerklassifikationen bilden die Grundlage für standardisierte Verfahren zur Fehlerbehandlung und unterstützen zudem eine kontinuierliche Qualitätsverbesserung im Sinne des <a href="Qualit%C3%A4tsmanagement" title="Qualitätsmanagement">Qualitätsmanagements</a>.“<sup id="cite_ref-BITKOM_19-0" class="reference"><a href="#cite_note-BITKOM-19"><span class="cite-bracket">[</span>19<span class="cite-bracket">]</span></a></sup> Weitere Angaben je Fehler wie eine ausführliche Fehlerbeschreibung, betroffene Programme, beteiligte Personen etc. begleiten die Maßnahmen zur Behebung der Fehler und dokumentieren diese. Näheres siehe BITKOM-Leitfaden.<sup id="cite_ref-BITKOM_19-1" class="reference"><a href="#cite_note-BITKOM-19"><span class="cite-bracket">[</span>19<span class="cite-bracket">]</span></a></sup>

</p><p>Vereinfachend werden Programmfehler im Fehlerbearbeitungsprozess häufig nur nach der <i>Fehlerschwere,</i> das schließt außerdem die Fehlerwirkung und den Behebungsaufwand ein, in Kategorien/Klassen wie A, B, C, … oder 1, 2, 3, … usw. eingeteilt. Beispiele siehe BITKOM-Leitfaden,<sup id="cite_ref-BITKOM_19-2" class="reference"><a href="#cite_note-BITKOM-19"><span class="cite-bracket">[</span>19<span class="cite-bracket">]</span></a></sup> insbesondere im Anhang.

</p>

<div class="mw-heading mw-heading2"><h2 id="Folgen_von_Programmfehlern">Folgen von Programmfehlern</h2></div>

<p>Die Folgen von Programmfehlern können hochgradig unterschiedlich sein und sich in vielfältiger Weise zeigen. Werden Fehler im Rahmen der Entwicklungsprozesse entdeckt, so beschränken sich die Fehlerfolgen außerdem auf die Überarbeitung der Software (Codekorrekturen, Konzeptüberarbeitung, Dokumentation …) – je nach Situation mit mehr oder weniger großen Auswirkung auf das Projektbudget und die Projektdauer. Dagegen wirken erst im Produktivbetrieb erkannte Fehler nicht selten ungleich kritischer, zum Beispiel können sie Prozess-Störungen oder Produktionsstillstand bewirken, Imageschäden hervorrufen, den Verlust von Kunden und Märkten verursachen, Regresspflichten auslösen oder gar das Unternehmen in Existenzgefahr bringen. Fehler in technischen Anwendungen können im schlimmsten Fall zu Katastrophen führen.

</p><p>Konkrete Beispiele für Programmfehler und deren Folgen finden sich in der <a href="Liste_von_Programmfehlerbeispielen" title="Liste von Programmfehlerbeispielen">Liste von Programmfehlerbeispielen</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Reproduzierbarkeit_von_Programmfehlern">Reproduzierbarkeit von Programmfehlern</h2></div>

<p>Manche Programmfehler sind nur äußerst schwer oder gar nicht zuverlässig reproduzierbar. Bei der Wiederholung eines zuvor gescheiterten Vorgangs unter scheinbar unveränderten Bedingungen ist die Wahrscheinlichkeit gegeben, dass sich diese Fehler nicht erneut äußern. Es gibt zwei mögliche Gründe für dieses Verhalten: Zum einen kann es zu Verzögerungen zwischen der Fehleraktivierung und dem letztlich auftretenden Problem beispielsweise einem Programmabsturz kommen, welche die tatsächliche Ursache verschleiern und deren Identifikation erschweren. Zum anderen können andere Elemente des Softwaresystems (Hardware, Betriebssystem, andere Programme) das Verhalten der Fehler in dem betrachteten Programm beeinflussen. Ein Beispiel hierfür sind Fehler, die in <a href="Nebenl%C3%A4ufigkeit" title="Nebenläufigkeit">nebenläufigen</a> Umgebungen mit mangelnder <a href="Synchronisation" title="Synchronisation">Synchronisation</a> (genauer: <a href="Sequentialisierung" title="Sequentialisierung">Sequentialisierung</a>) auftreten. Wegen der hieraus folgenden <a href="Race_Condition" class="mw-redirect" title="Race Condition">Wettlaufsituationen</a> <i>(Race Conditions)</i> können die Prozesse in einer Reihenfolge abgearbeitet werden, welche zu einem Laufzeitfehler führt. Bei einer Wiederholung der gleichen Aktion ist es möglich, dass die Reihenfolge der Prozesse unterschiedlich ist und kein Problem auftritt.

</p><p>Die Reproduzierbarkeit eines Programmfehlers lässt sich anhand dessen Beobachtungsgüte in Kategorien/Klassen wie A, B, C ... oder 1, 2, 3 ... usw. einteilen. Die Beobachtungsstufe eines Fehlers kann sich über die Nutzungszeit der Software verändern, so kann sich bspw. ein nicht reproduzierbarer Fehler zu einem eindeutig reproduzierbaren Fehler entwickeln. Bei nicht ohne weiteres reproduzierbaren Fehlern, welche aber wiederholt aufgetreten sind, können Experten zur Ursachensuche hinzugezogen werden.

</p>

<ul><li>A: Eindeutig festgestellter Fehler, welcher mit Belegen jederzeit reproduziert werden kann.</li>

<li>B: Nicht ohne weiteres reproduzierbarer Fehler, welcher aber nachweislich wiederholt aufgetreten ist.</li>

<li>C: Nicht reproduzierbarer und nicht nachweislich wiederholt aufgetretener Fehler.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weiterführende_Themen"><span id="Weiterf.C3.BChrende_Themen"></span>Weiterführende Themen</h2></div>

<ul><li>Zum Prinzip, noch „unreife“ Software auszuliefern, siehe <a href="Bananenware" class="mw-redirect" title="Bananenware">Bananenware</a>.</li>

<li>Software, die (oft kostenlos angeboten) z. B. Mängel in der Sicherheit, der Übersichtlichkeit oder ihrer nutzbaren Funktionalität aufweist; siehe <a href="Crapware" title="Crapware">Crapware</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>William E. Perry: <i>Software Testen.</i> Mitp-Verlag, Bonn 2002, ISBN 3-8266-0887-9.</li>

<li>Elfriede Dustin, Jeff Rashka, John Paul: <i>Software automatisch testen. Verfahren, Handhabung und Leistung.</i> Springer, Berlin u. a. 2001, ISBN 3-540-67639-2.</li>

<li>Cem Kaner, Jack Falk, Hung Quoc Nguyen: <i>Testing Computer Software.</i> 2nd edition. John Wiley & Sons, New York NY u. a. 1999, ISBN 0-471-35846-0.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<div class="sisterproject" style="margin:0.1em 0 0 0;"><span class="noviewer" style="display:inline-block; line-height:10px; min-width:1.6em; text-align:center;" aria-hidden="true" role="presentation"><span class="mw-default-size" typeof="mw:File"><span title="Wiktionary"></span></span></span><b><a href="https://de.wiktionary.org/wiki/Programmfehler" class="extiw external" title="wikt:Programmfehler">Wiktionary: Programmfehler</a></b> – Bedeutungserklärungen, Wortherkunft, Synonyme, Übersetzungen</div>

<ul><li><a rel="nofollow" class="external text" href="http://cwe.mitre.org/top25/">Die 25 gefährlichsten Programmierfehler</a> (englisch)</li>

<li><span class="cite">SQS: <a rel="nofollow" class="external text" href="http://www.computerwoche.de/a/die-spektakulaersten-softwarefehler-2012,2531034"><i>Die spektakulärsten Softwarefehler 2012.</i></a> In: <i>Computerwoche.</i> 17. Januar 2013,<span class="Abrufdatum"> abgerufen am 20. Januar 2013</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AProgrammfehler&rft.title=Die+spektakul%C3%A4rsten+Softwarefehler+2012&rft.description=Die+spektakul%C3%A4rsten+Softwarefehler+2012&rft.identifier=http%3A%2F%2Fwww.computerwoche.de%2Fa%2Fdie-spektakulaersten-softwarefehler-2012%2C2531034&rft.creator=SQS&rft.date=2013-01-17"> </span></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-PKS-1"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-PKS_1-0">a</a></sup> <sup><a href="#cite_ref-PKS_1-1">b</a></sup> <sup><a href="#cite_ref-PKS_1-2">c</a></sup></span> <span class="reference-text">M. Pol, T. Koomen, A. Spillner: <i>Management und Optimierung des Testprozesses.</i> dpunkt.Verlag, Heidelberg 2002, ISBN 3-89864-156-2.</span>

</li>

<li id="cite_note-ISO-9000-2"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-ISO-9000_2-0">a</a></sup> <sup><a href="#cite_ref-ISO-9000_2-1">b</a></sup></span> <span class="reference-text">DIN-Normenausschuss Qualitätsmanagement, Statistik und Zertifizierungsgrundlagen (NQSZ): <cite style="font-style:italic">DIN EN ISO 9000</cite>. Qualitätsmanagementsysteme - Grundlagen und Begriffe. Hrsg.: DIN Deutsches Institut für Normung e. V. Beuth Verlag GmbH, Berlin November 2015, 3.6.9, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>40</span> (104 S.).<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abookitem&rfr_id=info:sid/de.wikipedia.org:Programmfehler&rft.atitle=3.6.9&rft.au=DIN-Normenausschuss+Qualit%C3%A4tsmanagement%2C+Statistik+und+Zertifizierungsgrundlagen+%28NQSZ%29&rft.btitle=DIN+EN+ISO+9000&rft.date=2015-11&rft.genre=bookitem&rft.pages=40&rft.place=Berlin&rft.pub=Beuth+Verlag+GmbH" style="display:none"> </span></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><a href="#cite_ref-3">↑</a></span> <span class="reference-text">Spillner et al. <i>Praxiswissen Softwaretest - Testmanagement</i><style data-mw-deduplicate="TemplateStyles:r261891140">

/* start https://de.wikipedia.org/ */

.mw-parser-output .webarchiv-memento a{color:inherit}

/* end https://de.wikipedia.org/ */

</style><a rel="nofollow" class="external text" href="https://web.archive.org/web/20101217001244/https://www.dpunkt.de/leseproben/3028/Kapitel%201.pdf">Leseprobe Kap. 1.1 Basiswissen / <i>Fehlerbegriff</i></a> (<span class="webarchiv-memento"><a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a></span> vom 17. Dezember 2010 im <i><a href="Internet_Archive" title="Internet Archive">Internet Archive</a></i>) (PDF) dpunkt.de</span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><a href="#cite_ref-4">↑</a></span> <span class="reference-text">Merriam-Webster Unabridged Dictionary (iOS-App, 2016): <i>bug: a) an insect or other creeping or crawling invertebrate … b) any of certain insects commonly considered especially obnoxious … c) an insect of the order <a href="Hemiptera" class="mw-redirect" title="Hemiptera">Hemiptera</a>, especially: a member of the suborder <a href="Heteroptera" class="mw-redirect" title="Heteroptera">Heteroptera</a> …</i></span>

</li>

<li id="cite_note-5"><span class="mw-cite-backlink"><a href="#cite_ref-5">↑</a></span> <span class="reference-text">ein Wortspiel eines scheinbar lateinischen Gattungsnamens aus <i>call</i> (Anruf[en]) und <i>Bellum</i> (Akkusativ zu <a href="Alexander_Graham_Bell" title="Alexander Graham Bell">Bell</a>)</span>

</li>

<li id="cite_note-6"><span class="mw-cite-backlink"><a href="#cite_ref-6">↑</a></span> <span class="reference-text">Paul B. Israel (Hrsg.): <i>The Papers of Thomas A. Edison.</i> Vol. 4, Baltimore and London, 1993 (<a rel="nofollow" class="external text" href="https://catalogue.swanngalleries.com/asp/fullCatalogue.asp?salelot=2470++++++41+&refno=++743398&saletype=">Online</a>).</span>

</li>

<li id="cite_note-7"><span class="mw-cite-backlink"><a href="#cite_ref-7">↑</a></span> <span class="reference-text">Fred R. Shapiro: <i>Etymology of the Computer Bug: History and Folklore.</i> In: <i>American Speech.</i> Band 62, Nr. 4, 1987, S. 376–378.</span>

</li>

<li id="cite_note-UniO-8"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-UniO_8-0">a</a></sup> <sup><a href="#cite_ref-UniO_8-1">b</a></sup></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20230328093835/http://www.informatik.uni-oldenburg.de/~iug10/sli/index01ce.html?q=node/25"><i>Sicherheitslücken im Internet – Fehler im Programmcode.</i></a> In: <i>informatik.uni-oldenburg.de.</i> Archiviert vom <style data-mw-deduplicate="TemplateStyles:r250917974">

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><span class="dewiki-iconexternal"><a class="external text" href="https://redirecter.toolforge.org/?url=http%3A%2F%2Fwww.informatik.uni-oldenburg.de%2F%7Eiug10%2Fsli%2Findex01ce.html%3Fq%3Dnode%2F25">Original</a></span> am <span style="white-space:nowrap;">28. März 2023</span><span>;</span><span class="Abrufdatum"> abgerufen am 22. Juli 2024</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AProgrammfehler&rft.title=Sicherheitsl%C3%BCcken+im+Internet+%E2%80%93+Fehler+im+Programmcode&rft.description=Sicherheitsl%C3%BCcken+im+Internet+%E2%80%93+Fehler+im+Programmcode&rft.identifier=https%3A%2F%2Fweb.archive.org%2Fweb%2F20230328093835%2Fhttp%3A%2F%2Fwww.informatik.uni-oldenburg.de%2F%7Eiug10%2Fsli%2Findex01ce.html%3Fq%3Dnode%2F25&rft.source=http://www.informatik.uni-oldenburg.de/~iug10/sli/index01ce.html?q=node/25"> </span></span>

</li>

<li id="cite_note-9"><span class="mw-cite-backlink"><a href="#cite_ref-9">↑</a></span> <span class="reference-text"><a href="IX_%E2%80%93_Magazin_f%C3%BCr_professionelle_Informationstechnik" title="IX – Magazin für professionelle Informationstechnik">iX-Magazin</a>, Studie <i>Software-Testmanagement</i>, war früher <a rel="nofollow" class="external text" href="https://web.archive.org/web/20130109024912/http://www.heise.de/kiosk/special/ixstudie/06/01">im IX Kiosk erwerbbar</a> (<span class="webarchiv-memento"><a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a></span> vom 9. Januar 2013 im <i><a href="Internet_Archive" title="Internet Archive">Internet Archive</a></i>)</span>

</li>

<li id="cite_note-10"><span class="mw-cite-backlink"><a href="#cite_ref-10">↑</a></span> <span class="reference-text">Herbert Krasner: <cite class="lang" lang="en" dir="auto" style="font-style:italic">The Cost of Poor Software Quality in the US</cite>. A 2022 Report - From Problem to Solutions. Hrsg.: Consortium for Information & Software Quality. 15. Dezember 2022, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>3–4</span> (englisch, 61 S., <a rel="nofollow" class="external text" href="https://www.it-cisq.org/wp-content/uploads/sites/6/2022/11/CPSQ-Report-Nov-22-2.pdf">it-cisq.org</a> [PDF; abgerufen am 25. September 2024]).<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Programmfehler&rft.au=Herbert+Krasner&rft.btitle=The+Cost+of+Poor+Software+Quality+in+the+US&rft.date=2022-12-15&rft.genre=book&rft.pages=3-4" style="display:none"> </span></span>

</li>

<li id="cite_note-Wallm_SWQ-11"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-Wallm_SWQ_11-0">a</a></sup> <sup><a href="#cite_ref-Wallm_SWQ_11-1">b</a></sup></span> <span class="reference-text">Wallmüller: <i>Software-Qualitätsmanagement in der Praxis,</i> <a rel="nofollow" class="external text" href="http://www.beck-shop.de/fachbuch/leseprobe/9783446213678_Excerpt_001.pdf">beck-shop.de</a> (PDF; 612 kB), Hanser, München 2001, ISBN 978-3-446-21367-8.</span>

</li>

<li id="cite_note-12"><span class="mw-cite-backlink"><a href="#cite_ref-12">↑</a></span> <span class="reference-text">Junginger: <i>Wertorientierte Steuerung von Risiken im Informationsmanagement</i>. 2005, ISBN 3-8244-8225-8.</span>

</li>

<li id="cite_note-13"><span class="mw-cite-backlink"><a href="#cite_ref-13">↑</a></span> <span class="reference-text">Steve C. McConnel: <cite class="lang" lang="en" dir="auto" style="font-style:italic">Code Complete</cite>. 2. Auflage. Microsoft Press, 2004, ISBN 0-7356-1967-0, 20.5, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>474</span> (englisch, 914 S.): <span class="lang" lang="en" dir="auto">“The single biggest activity on most projects is debugging and correcting code that doesn’t work properly. Debugging and associated rework consume about 50 percent of the time on a traditional, naive software-development cycle.”</span><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abookitem&rfr_id=info:sid/de.wikipedia.org:Programmfehler&rft.atitle=20.5&rft.au=Steve+C.+McConnel&rft.btitle=Code+Complete&rft.date=2004&rft.edition=2&rft.genre=bookitem&rft.isbn=0735619670&rft.pages=474&rft.pub=Microsoft+Press" style="display:none"> </span></span>

</li>

<li id="cite_note-14"><span class="mw-cite-backlink"><a href="#cite_ref-14">↑</a></span> <span class="reference-text">Capers Jones: <cite class="lang" lang="en" dir="auto" style="font-style:italic">Software Assessments, Benchmarks, and Best Practices</cite>. Addison-Wesley, 2000, ISBN 0-201-48542-7, <span style="white-space:nowrap">Kap.<span style="display:inline-block;width:.2em"> </span>3</span>, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>99</span> (englisch, <a rel="nofollow" class="external text" href="https://archive.org/details/softwareassessme0000jone/mode/2up">archive.org</a> [abgerufen am 29. Mai 2022]): <span class="lang" lang="en" dir="auto">“The relationship between quality and productivity is well supported by emperical data, even if the topic is not well understood by the industry as a whole. As far back as the early 1970s, IBM discovered that software projects with the lowest levels of defects had the shortest development schedules and the highest development productivity. The reason for this situation is because software defect removal is actually the most expensive and time-consuming form of work for software.”</span><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abookitem&rfr_id=info:sid/de.wikipedia.org:Programmfehler&rft.atitle=3&rft.au=Capers+Jones&rft.btitle=Software+Assessments%2C+Benchmarks%2C+and+Best+Practices&rft.date=2000&rft.genre=bookitem&rft.isbn=0201485427&rft.pages=99&rft.pub=Addison-Wesley" style="display:none"> </span></span>

</li>

<li id="cite_note-15"><span class="mw-cite-backlink"><a href="#cite_ref-15">↑</a></span> <span class="reference-text">Georg Edwin Thaller <i>Softwaretest, Verifikation und Validation</i> 2002, ISBN 978-3-88229-198-8.</span>

</li>

<li id="cite_note-16"><span class="mw-cite-backlink"><a href="#cite_ref-16">↑</a></span> <span class="reference-text">John Ronald-Cummings, Peer Owais: <cite class="lang" lang="en" dir="auto" style="font-style:italic">Leading Quality</cite>. How Great Leaders Deliver High Quality Software and Accelerate Growth. Hrsg.: ROI Press. 2019, ISBN 978-1-916185-80-7, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>64</span> (englisch, 154 S.): <span class="lang" lang="en" dir="auto">“Research by Capers Jones found that the cost to address bugs post-release is $16,000, but a bug found at the design phase costs $25.”</span><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Programmfehler&rft.au=John+Ronald-Cummings%2C+Peer+Owais&rft.btitle=Leading+Quality&rft.date=2019-07-30&rft.genre=book&rft.isbn=9781916185807&rft.pages=64" style="display:none"> </span></span>

</li>

<li id="cite_note-17"><span class="mw-cite-backlink"><a href="#cite_ref-17">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="http://my.safaribooksonline.com/book/-/9781457170911/19-abweichungsmanagement/255">my.safaribooksonline.com</a></span>

</li>

<li id="cite_note-IEEE_1044en-18"><span class="mw-cite-backlink"><a href="#cite_ref-IEEE_1044en_18-0">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://standards.ieee.org/findstds/standard/1044-2009.html"><i>IEEE Standard Classification for Software Anomalies.</i></a> (PDF) IEEE Standards Board, 1993, <span style="white-space:nowrap;">S. 32</span>,<span class="Abrufdatum"> abgerufen am 22. November 2014</span> (White Paper; Dokument hinter Paywall).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AProgrammfehler&rft.title=IEEE+Standard+Classification+for+Software+Anomalies&rft.description=IEEE+Standard+Classification+for+Software+Anomalies&rft.identifier=https%3A%2F%2Fstandards.ieee.org%2Ffindstds%2Fstandard%2F1044-2009.html&rft.publisher=IEEE+Standards+Board&rft.date=1993"> </span></span>

</li>

<li id="cite_note-BITKOM-19"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-BITKOM_19-0">a</a></sup> <sup><a href="#cite_ref-BITKOM_19-1">b</a></sup> <sup><a href="#cite_ref-BITKOM_19-2">c</a></sup></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-Fehlerklassifikation-fuer-Software.html"><i>Bitkom Leitfaden Fehlerklassifikation für Software | Bitkom e. V.</i></a><span class="Abrufdatum"> Abgerufen am 26. Juli 2022</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AProgrammfehler&rft.title=Bitkom+Leitfaden+Fehlerklassifikation+f%C3%BCr+Software+%7C+Bitkom+e.%26nbsp%3BV.&rft.description=Bitkom+Leitfaden+Fehlerklassifikation+f%C3%BCr+Software+%7C+Bitkom+e.%26nbsp%3BV.&rft.identifier=https%3A%2F%2Fwww.bitkom.org%2FBitkom%2FPublikationen%2FBitkom-Leitfaden-Fehlerklassifikation-fuer-Software.html&rft.language=de"> </span></span>

</li>

</ol></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-12-11" href="https://de.wikipedia.org/wiki/?title=Programmfehler&oldid=262311518">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>